Workflow-Enabled Services
Only a workflow that uses the WebServiceReceive activity can be published as a Web service. A simple scenario would be to create a workflow project and add WebServiceReceive and WebServiceResponse
activities to it. In this case, the workflow is activated by calling a
method on the Web service and returning a value when the processing is
complete. In Visual Studio, a workflow project can be published as a Web
service by right-clicking on a workflow project and selecting “Publish
as Web service.” This action will create an ASP.NET project, with ASMX
and Web.Config files.
Versioning Orchestrations
Orchestrations in WF can be versioned in two ways:
1. | Execute the XOML file– In this case, the service reads the .XOML file and creates a Workflow instance using the CreateWorkflow method. The XOML file does not support versioning; the file can be manually versioned.
|
2. | Use assembly level versioning–
Each assembly has a version number, and two assemblies that differ by
version number are considered by the runtime to be different assemblies.
The assembly version can be managed by modifying the assembly.cs file prior to deployment.
|
Note that because with
assembly-level versioning a new version of a workflow is treated as a
new assembly version by the runtime, different assembly versions can run
concurrently.
WF Extensibility
WF provides various
extensibility points that are broad and do not impose semantics on the
user. For example, if we are extending the persistence mechanism, WF
does not stipulate that we use either the data-store or the
serialization techniques.
WF’s extensibility model allows almost every aspect of WF to be extended. Some common extensibility requirements include:
creating custom policies
creating workflow tracking services
adding new activities for persistence, tracking, and communication
creating domain-specific activities
WF has a visual designer used in Visual Studio that can also be extended to create domain-specific designers.
Business Rules
A service-oriented solution
is typically modeled so as to factor out task services because these
services encapsulate business non-agnostic activities specific to the
overarching business process. The WF visual designer can be used to glue
together various business activities that involve business rules that
are exposed in one of two ways:
1. | Conditions
can be used with built-in and custom activities to change their
execution behavior. There are several built-in rules-based activities
that enable conditional logic:
IfElse (provides decision logic) While (provides looping behavior) Replicator (analogous to a for-each statement)
Also supported is the conditioned activity group (CAG) that can provide rules-driven behavior over a collection of activities.
|
2. | PolicyActivity,
a rules engine that comes embedded with WF, can be used with a
specialized workflow activity class that encapsulates a RuleSet which is
stored in a .rules file. At runtime, PolicyActivity retrieves the rules
from the .rules file and executes the rules.
|
The PolicyActivity engine can be used to apply Rules Centralization so as to centralize business rules logic in the RuleSet, effectively establishing a rules service.
